home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 8_1_10.tro < prev    next >
Text File  |  1991-12-22  |  70KB  |  2,685 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright (~c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v'|.5i'
  22. .sp 2P
  23. .LP
  24. \fBRecommendation\ V.120\fR 
  25. .RT
  26. .sp 2P
  27. .ce 1000
  28. \fBSUPPORT\ BY\ AN\ ISDN\ OF\ DATA\ TERMINAL\ EQUIPMENT\fR 
  29. .EF '%    Fascicle\ VIII.1\ \(em\ Rec.\ V.120''
  30. .OF '''Fascicle\ VIII.1\ \(em\ Rec.\ V.120    %'
  31. .ce 0
  32. .ce 1000
  33. \fBWITH\ V\(hySERIES\ TYPE\ INTERFACES\ WITH\ PROVISION\fR 
  34. .ce 0
  35. .sp 1P
  36. .ce 1000
  37. \fBFOR\ STATISTICAL\ MULTIPLEXING\fR 
  38. .ce 0
  39. .sp 1P
  40. .ce 1000
  41. \fI(Melbourne, 1988)\fR 
  42. .sp 9p
  43. .RT
  44. .ce 0
  45. .sp 1P
  46. .LP
  47.     The\ CCITT,
  48. .sp 1P
  49. .RT
  50. .sp 1P
  51. .LP
  52. \fIconsidering\fR 
  53. .sp 9p
  54. .RT
  55. .PP
  56. (a)
  57. that the ISDN will offer the universal interfaces to
  58. connect subscriber terminals in accordance with the reference configuration
  59. described in Recommendation\ I.411;
  60. .PP
  61. (b)
  62. that during the evolution of ISDN there will exist for a considerable period 
  63. DTEs with V\(hySeries interfaces which need to connect to 
  64. ISDN;
  65. .PP
  66. (c)
  67. that it would be desirable that terminals with V\(hySeries interfaces interwork 
  68. easily with ISDN TE1s; 
  69. .PP
  70. (d)
  71. that statistical multiplexing provides improved
  72. utilization of bandwidth in some applications;
  73. .PP
  74. (e)
  75. that the D channel signalling protocol is described in Recommendations\ 
  76. I.430, I.431, Q.921 and Q.931; 
  77. .PP
  78. (f)
  79. that there exists CCITT Recommendation V.110 for
  80. adapting DTEs with a V\(hySeries interface onto B\ Channels;
  81. .sp 1P
  82. .LP
  83. \fIunanimously declares\fR 
  84. .sp 9p
  85. .RT
  86. .PP
  87. (1)
  88. that the scope of this Recommendation shall cover the
  89. connection to the ISDN of terminals with interfaces for modems conforming to
  90. current V\(hySeries Recommendations, operating in accordance with circuit or
  91. leased circuit bearer services on bearer channels (B, H0, H11 or H12)
  92. (see Note);
  93. .PP
  94. (2)
  95. that the following circuit\(hyswitched services may be
  96. supported:
  97. .LP
  98.     \(em
  99.     multiplexing of several data links on a single bearer
  100. channel; (and/or)
  101. .LP
  102.     \(em
  103.     automatic establishment and disestablishment of additional
  104. data links;
  105. .PP
  106. (3)
  107. that the reference configurations of \(sc 1 shall apply;
  108. .PP
  109. (4)
  110. that the terminal adaptor (TA) functions necessary to
  111. support the connection of DTEs with V\(hySeries type interfaces on an ISDN 
  112. shall include the following: 
  113. .LP
  114.     \(em
  115.     conversion of the electrical and mechanical interface
  116. characteristics;
  117. .LP
  118.     \(em
  119.     bit rate adaption;
  120. .LP
  121.     \(em
  122.     end\(hyto\(hyend synchronization;
  123. .LP
  124.     \(em
  125.     call establishment and disestablishment based on either
  126. manual or automatic calling and/or answering;
  127. .LP
  128.     \(em
  129.     maintenance functions.
  130. .PP
  131. \fINote\fR \ \(em\ The compatibility of V.120 with protocols developed in
  132. other Study Groups for Additional Packet Mode Bearer Service (APMBS) as 
  133. defined in Recommendation\ I.122 is for further study and the provisions 
  134. of this 
  135. Recommendation, V.120, shall not prejudice this study.
  136. .PP
  137. Significant further study related both to aspects of the protocol and the 
  138. alignment with other ISDN protocols is needed on this Recommendation. 
  139. .RT
  140. .sp 2P
  141. .LP
  142. \fB1\fR     \fBReference configurations\fR 
  143. .sp 1P
  144. .RT
  145. .sp 1P
  146. .LP
  147. 1.1
  148.     \fICustomer access configurations\fR 
  149. .sp 9p
  150. .RT
  151. .PP
  152. There are two basic classes of devices capable of data transmission in 
  153. the ISDN environment: 
  154. .RT
  155. .LP
  156.     \(em
  157.     devices directly attached to the ISDN, i.e. TE1s; and
  158. .LP
  159.     \(em
  160.      devices attached to the ISDN through a terminal adaptor, i.e. V\(hySeries 
  161. TE2s. 
  162. .bp
  163. .sp 1P
  164. .LP
  165. 1.2
  166.     \fIConnectivity\fR 
  167. .sp 9p
  168. .RT
  169. .PP
  170. ISDN connectivity requirements include support for TE1\(hyto\(hyTE1,
  171. TE2\(hyto\(hyTE2 (TA\(hyto\(hyTA) and TE1\(hyto\(hyTE2 (TE1\(hyto\(hyTA) 
  172. connections as discussed and illustrated in Figure\ 1/V.120. This document 
  173. specifies a terminal adaption 
  174. protocol based on a modification of LAPD that supports these connections. 
  175. LAPD is specified in CCITT Recommendation\ Q.921. The modifications are 
  176. specified in \(sc\ 2.4 of this Recommendation. 
  177. .PP
  178. This protocol provides a consistent protocol for carrying
  179. different types of data streams (see \(sc\(sc\ 3.3 to\ 3.5). This approach 
  180. using a HDLC based protocol provides the capability for multiplexing multiple 
  181. logical 
  182. circuits on a channel. This also allows for different higher layer protocols 
  183. to be running concurrently on a single channel (see\ \(sc\ 2.2). 
  184. .PP
  185. In come cases the speed of the communicating TE2s is the same. It is possible 
  186. in certain cases to connect devices with different speeds using the 
  187. frame encapsulation procedures described later in \(sc\ 2, and in more 
  188. detail in 
  189. \(sc\ 3. The key factors that make this concept viable are TA buffering, 
  190. TA flow 
  191. control, HDLC encapsulation and HDLC flow control.
  192. .PP
  193. The application of this protocol to TE1\(hyto\(hyTA applications is
  194. discussed in Appendix\ I.
  195. .PP
  196. Within I.515, parameter exchange procedureds are \fIgenerally described\fR 
  197. to allow interworking between incompatible terminal adaptors (TAs) that 
  198. may not require interworking functions within the network. Interworking 
  199. between 
  200. different types of TAs can be accomplished with Multifunctional Terminal
  201. Adaptors (MTAs) that are capable of supporting more than one protocol. 
  202. However, Figure\ 1/I.515 also depicts other interworking scenarios that 
  203. will require IWFs when TAs are not capable of supporting more than one 
  204. protocol. 
  205. .RT
  206. .LP
  207. .rs
  208. .sp 15P
  209. .ad r
  210. \fBFigure 1/V.120, p.\fR 
  211. .sp 1P
  212. .RT
  213. .ad b
  214. .RT
  215. .sp 2P
  216. .LP
  217. \fB2\fR     \fBData transport protocol specification\fR 
  218. .sp 1P
  219. .RT
  220. .PP
  221. This protocol relies on procedures similar to those in CCITT\ 1986 Recommendation\ 
  222. Q.921/I.441. It provides the capability for use with compatible TE1 or 
  223. TA equipments. 
  224. .PP
  225. The use in TE1s of the protocols specified in this document is
  226. described in Appendix\ I. The remainder of this document is concerned with 
  227. their use in TAs. 
  228. .RT
  229. .sp 2P
  230. .LP
  231. 2.1
  232.     \fIFunctions provided by protocol\fR 
  233. .sp 1P
  234. .RT
  235. .sp 1P
  236. .LP
  237. 2.1.1
  238.     \fICategories of functions\fR 
  239. .sp 9p
  240. .RT
  241. .PP
  242. There are two categories of functions provided by this specified
  243. protocol. There is a set of base functions and a set of additional functions. 
  244. The additional functions depend upon the type of data flow (character coded 
  245. or message). 
  246. .bp
  247. .RT
  248. .sp 1P
  249. .LP
  250. 2.1.2
  251.     \fIBase functions\fR 
  252. .sp 9p
  253. .RT
  254. .PP
  255. The base functions of the protocol include the following:
  256. .RT
  257. .LP
  258.     \(em
  259.     transparent transport of data;
  260. .LP
  261.     \(em
  262.     generation and interpretation of messages for peer
  263. communication (i.e.\ post call connection hand
  264. shake);
  265. .LP
  266.     \(em
  267.     administration of timers and counters used in communication;
  268. .LP
  269.     \(em
  270.     error detection.
  271. .sp 1P
  272. .LP
  273. 2.1.3
  274.     \fIAdditional functions\fR 
  275. .sp 9p
  276. .RT
  277. .PP
  278. The additional functions of the protocol include the
  279. following:
  280. .RT
  281. .LP
  282.     \(em
  283.     transport and interpretation of interface status change at
  284. the R reference point;
  285. .LP
  286.     \(em
  287.     segmenting and reassembly of messages;
  288. .LP
  289.     \(em
  290.     transport of detected interface errors at the R reference
  291. point;
  292. .LP
  293.     \(em
  294.     support for operation with a network independent clock;
  295. .LP
  296.     \(em
  297.     multiplexing of synchronous and asynchronous protocols;
  298. .LP
  299.     \(em
  300.     interworking of two TEs operating at different data rates;
  301. .LP
  302.     \(em
  303.     flow control;
  304. .LP
  305.     \(em
  306.     retransmission on error detection.
  307. .sp 1P
  308. .LP
  309. 2.2
  310.     \fIGeneral\fR 
  311. \fIterminal adaption\fR 
  312. .sp 9p
  313. .RT
  314. .PP
  315. The terminal adaption mechanisms are divided into two general
  316. categories:
  317. .RT
  318. .LP
  319.     \(em
  320.     protocol sensitive operation for character or message
  321. encapsulation; and
  322. .LP
  323.     \(em
  324.      bit transparent operation where no alignment (above the bit level) of 
  325. information from the interface at the R\ reference point is made 
  326. within the frame transport in the bearer channel.
  327. .PP
  328. The interface bit rate at the R reference point must be less than the bearer 
  329. channel capability. The terminal adaptor may support single or 
  330. multiple interfaces at the R\ reference point. In the later case the protocol
  331. applies separately to the data streams associated with each interface. 
  332. The use of logical link identifiers to distinguish between data streams 
  333. will be 
  334. described.
  335. .sp 1P
  336. .LP
  337. 2.2.1
  338.     \fIProtocol sensitive operation with start/stop mode TE2s\fR 
  339. \fI(asynchronous mode)\fR 
  340. .sp 9p
  341. .RT
  342. .PP
  343. The start and stop bits are removed and parity may be checked (see \(sc\ 
  344. 3.3.1). The resultant character(s) is placed in a frame for transport on 
  345. the bearer channel to a peer entity. The peer entity may be in a peer TA 
  346. where the reverse process takes place to another interface at an R\ reference 
  347. point, or 
  348. the peer entity may be in a TE1 where the character(s) is passed to a higher
  349. layer within the TE1, or in an interworking function. Errors detected on the
  350. interface at the R\ reference point are relayed to the peer entity which
  351. will:
  352. .RT
  353. .LP
  354.     1)
  355.     notify the higher layer of the detected error; or
  356. .LP
  357.     2)
  358.     replicate the error (see \(sc\(sc 3.3.1 and 3.3.2) at the
  359. outbound interface at the R\ reference point.
  360. .PP
  361. The terminal adaptor will recognize and remove any erroneous NULL characters 
  362. (created by the initiation of BREAK) before transmission. 
  363. .sp 1P
  364. .LP
  365. 2.2.2
  366.     \fIProtocol sensitive operation with synchronous HDLC TE2s\fR 
  367. \fI(synchronous mode)\fR 
  368. .sp 9p
  369. .RT
  370. .PP
  371. The flags and zero bit insertion are removed and the FCS is checked and 
  372. removed but the address, control, and information fields flow transparently 
  373. through the TA. The resultant octet\(hyaligned message is placed in one 
  374. or more 
  375. frames for transport to a peer entity over the data link connection on the
  376. bearer channel. The original message from the interface at the R\ reference
  377. point may be segmented within the TA and forwarded in parts to the peer 
  378. entity. This segmenting and forwarding process may occur as the message 
  379. is received. 
  380. This avoids the delays associated with accumulating a full message. The peer
  381. entity performs the reverse process at the peer interface R\ reference point.
  382. .bp
  383. .PP
  384. If an FCS error is detected at the interface at the R reference point, 
  385. this is relayed to the peer entity which will either: 
  386. .RT
  387. .LP
  388.     1)
  389.     discard the entire message; or
  390. .LP
  391.     2)
  392.     cause an abort to be sent on the interface at the R
  393. reference point in the message which is in progress; or
  394. .LP
  395.     3)
  396.     generate an incorrect FCS in the message which is in
  397. progress.
  398. .PP
  399. \fINote\fR \ \(em\ Support of non\(hyoctet aligned messages is for further
  400. study.
  401. .sp 1P
  402. .LP
  403. 2.2.3
  404.     \fITransport operation (bit transparent mode)\fR 
  405. .sp 9p
  406. .RT
  407. .PP
  408. In bit transparent operation the TA will encapsulate the bits from the 
  409. interface at the R\ reference point into frames as they are received. These 
  410. frames are forwarded to a peer entity. The peer TA removes the bits from 
  411. the 
  412. frames and sends them on the interface at the R\ reference point. No processing 
  413. or modification of the bits is performed and there is no checking fot bit 
  414. stream errors on the interface at the R\ reference point. This mode is 
  415. used for all modes not covered by the asynchronous or synchronous modes 
  416. defined above. 
  417. .PP
  418. \fINote\fR \ \(em\ In many cases UI frames will be used to convey frames 
  419. in this mode. 
  420. .RT
  421. .sp 1P
  422. .LP
  423. 2.3
  424.     \fIGeneral messages and formats\fR 
  425. .sp 9p
  426. .RT
  427. .PP
  428. The frame structure used is that specified in
  429. Recommendation\ Q.921/I.441. There is an optional one or two octet header. 
  430. The header octet(s), when present, directly follows the control field of 
  431. the V.120 frame as shown in Figure\ 2/V.120. 
  432. .RT
  433. .LP
  434. .rs
  435. .sp 26P
  436. .ad r
  437. \fBFigure 2/V.120, p.\fR 
  438. .sp 1P
  439. .RT
  440. .ad b
  441. .RT
  442. .LP
  443. .bp
  444. .sp 1P
  445. .LP
  446. 2.3.1
  447.     \fIAddress field\fR 
  448. .sp 9p
  449. .RT
  450. .PP
  451. The format of the V.120 address field in Figure 2/V.120 is similar to that 
  452. specified in Recommendation\ Q.921/I.441. The LLI0 and LLI1 fields may 
  453. be viewed as a single 13\ bit logical link identifier (LLI) field or 
  454. alternatively as two separate fields. This is shown in Figure\ 3/V.120.
  455. .RT
  456. .LP
  457. .rs
  458. .sp 15P
  459. .ad r
  460. \fBFigure 3/V.120 [T1.120], p.\fR 
  461. .sp 1P
  462. .RT
  463. .ad b
  464. .RT
  465. .PP
  466. .sp 2
  467. The LLI is considered to be the concatenation of the LLI0 field
  468. with the LLI1 field. The LLI can take on values in the range\ 0\(hy8191.
  469. Table\ 1/V.120 indicates values that are reserved.
  470. .ce
  471. \fBH.T. [T2.120]\fR 
  472. .ce
  473. TABLE\ 1/V.120
  474. .ce
  475. \fBReserved LLI values\fR 
  476. .ps 9
  477. .vs 11
  478. .nr VS 11
  479. .nr PS 9
  480. .TS
  481. center box;
  482. cw(36p) | cw(120p) .
  483. LLI    Function
  484. _
  485. .T&
  486. cw(36p) | lw(120p) .
  487. 0    In\(hychannel signalling
  488. _
  489. .T&
  490. cw(36p) | lw(120p) .
  491. 1\(hy255    T{
  492. Reserved for future standardization
  493. T}
  494. _
  495. .T&
  496. cw(36p) | lw(120p) .
  497. 256    Default LLI 
  498. _
  499. .T&
  500. cw(36p) | lw(120p) .
  501. 257\(hy2047    For LLI assignment
  502. _
  503. .T&
  504. cw(36p) | lw(120p) .
  505. 2048\(hy8190    T{
  506. Reserved for future standardization
  507. T}
  508. _
  509. .T&
  510. cw(36p) | lw(120p) .
  511. 8191    T{
  512. In\(hychannel layer management
  513. T}
  514. _
  515. .TE
  516. .nr PS 9
  517. .RT
  518. .ad r
  519. \fBTableau 1/V.120 [T2.120], p.\fR 
  520. .sp 1P
  521. .RT
  522. .ad b
  523. .RT
  524. .LP
  525. .bp
  526. .sp 1P
  527. .LP
  528. 2.3.2
  529.     \fIAddress extension bit (EA)\fR 
  530. .sp 9p
  531. .RT
  532. .PP
  533. The address field range is extended by using bit 1, the first
  534. transmitted bit, of the address field octets to indicate the final octet 
  535. of the address field. The presence of a \*Q1\*U in bit\ 1 of an address 
  536. field octet signals that it is the final octet of the address field. 
  537. .RT
  538. .sp 1P
  539. .LP
  540. 2.3.3
  541.     \fIC/R bit\fR 
  542. .sp 9p
  543. .RT
  544. .PP
  545. The C/R bit identifies a V.120 frame as either a command or a
  546. response (see \(sc\ 2.4). The C/R\ bit is employed symmetrically for the two
  547. directions of transmission and is coded as shown in Table\ 2/V.120.
  548. .RT
  549. .LP
  550. .ce
  551. \fBH.T. [T3.120]\fR 
  552. .ce
  553. TABLE\ 2/V.120
  554. .ce
  555. \fBCoding of C/R bit\fR 
  556. .ps 9
  557. .vs 11
  558. .nr VS 11
  559. .nr PS 9
  560. .TS
  561. center box;
  562. cw(18p) | cw(60p) .
  563. C/R    Meaning
  564. _
  565. .T&
  566. cw(18p) | lw(60p) .
  567. 0    Command
  568. _
  569. .T&
  570. cw(18p) | lw(60p) .
  571. 1    Response
  572. _
  573. .TE
  574. .nr PS 9
  575. .RT
  576. .ad r
  577. \fBTable 2/V.120 [T3.120], p.\fR 
  578. .sp 1P
  579. .RT
  580. .ad b
  581. .RT
  582. .sp 1P
  583. .LP
  584. .sp 2
  585. 2.3.4
  586.     \fIControl field\fR 
  587. .sp 9p
  588. .RT
  589. .PP
  590. The use of the V.120 control field is described in \(sc 2.4.
  591. .RT
  592. .sp 1P
  593. .LP
  594. 2.3.5
  595.     \fIHeader octet\fR 
  596. .sp 9p
  597. .RT
  598. .PP
  599. The format of the header octet is shown in Figure 4/V.120 (see
  600. \(sc\(sc\ 3.3 to 3.5 for details on the use of these fields). The header 
  601. octet is 
  602. mandatory for protocol sensitive modes and is optional for bit transparent
  603. mode.
  604. .RT
  605. .LP
  606. .rs
  607. .sp 12P
  608. .ad r
  609. \fBFigure 4/V.120 [T4.120], p.\fR 
  610. .sp 1P
  611. .RT
  612. .ad b
  613. .RT
  614. .LP
  615. .bp
  616. .sp 1P
  617. .LP
  618. 2.3.5.1
  619.     \fIE\(hyextension bit\fR \fI(bit 8)\fR 
  620. .sp 9p
  621. .RT
  622. .PP
  623. The E bit is the header extension bit. It allows for extension of the header 
  624. to provide additional control state information. A \*Q0\*U\ bit indicates 
  625. that a control state information octet follows (see \(sc\ 2.3.6). 
  626. .RT
  627. .sp 1P
  628. .LP
  629. 2.3.5.2
  630.     \fIBR\(hybreak/HDLC idle bit\fR \fI(bit 7)\fR 
  631. .sp 9p
  632. .RT
  633. .PP
  634. In asynchronous applications, the break bit indicates the
  635. invocation of the BREAK function by the TE2. A \*Q1\*U in this bit position
  636. indicates BREAK (see \(sc\ 3.3).
  637. .PP
  638. In protocol sensitive operation for synchronous HDLC applications, the 
  639. BR\ bit is used to indicate an HDLC idle condition on the interface at 
  640. the 
  641. R\ reference point. A \*Q1\*U in this bit position indicates that the interface 
  642. at the R\ reference point is receiving HDLC idle condition (see \(sc\ 3.4). 
  643. .RT
  644. .sp 1P
  645. .LP
  646. 2.3.5.3
  647.     \fIBits 5 and 6\fR 
  648. .sp 9p
  649. .RT
  650. .PP
  651. Bit 5 and bit 6 of the header octet are reserved and set to
  652. \*Q0\*U.
  653. .RT
  654. .sp 1P
  655. .LP
  656. 2.3.5.4
  657.     \fIC1, C2\(hyerror control (bits 3 and 4)\fR 
  658. .sp 9p
  659. .RT
  660. .PP
  661. Bit 3 and bit 4 of the header octet are defined as Control 1 and
  662. Control 2 respectively and are used for TA error detection and transmission.
  663. .PP
  664. The meanings of the C1 and C2 bits are encoded as shown in
  665. Table\ 3/V.120.
  666. .RT
  667. .ce
  668. \fBH.T. [T5.120]\fR 
  669. .ce
  670. TABLE\ 3/V.120
  671. .ce
  672. \fBCoding of C1 and C2 bits\fR 
  673. .ps 9
  674. .vs 11
  675. .nr VS 11
  676. .nr PS 9
  677. .TS
  678. center box;
  679. cw(12p) | cw(12p) | cw(60p) sw(60p) sw(60p) , ^  | ^  | c | c | c.
  680. C1    C2    Meaning
  681.         Synchronous    Asynchronous mode    Bit transparent mode
  682. _
  683. .T&
  684. cw(12p) | cw(12p) | lw(60p) | lw(60p) | lw(60p) .
  685. 0    0    No error detected    No error detected    No error detected
  686. _
  687. .T&
  688. cw(12p) | cw(12p) | lw(60p) | lw(60p) | lw(60p) .
  689. 0    1    FCS error (interface at R)    Stop\(hybit error    Not applicable
  690. _
  691. .T&
  692. cw(12p) | cw(12p) | lw(60p) | lw(60p) | lw(60p) .
  693. 1    0    Abort    T{
  694. Parity error on the last character in frame
  695. T}    Not applicable
  696. _
  697. .T&
  698. cw(12p) | cw(12p) | lw(60p) | lw(60p) | lw(60p) .
  699. 1    1    T{
  700. TA overrun (from interface at the R reference point)
  701. T}    T{
  702. Both stop\(hybit and parity error
  703. T}    Not applicable
  704. _
  705. .TE
  706. .nr PS 9
  707. .RT
  708. .ad r
  709. \fBTable 3/V.120 [T5.120], p.\fR 
  710. .sp 1P
  711. .RT
  712. .ad b
  713. .RT
  714. .sp 1P
  715. .LP
  716. .sp 1
  717. 2.3.5.5
  718.     \fIB, F\(hysegmentation bits\fR \fI(bit 2 and bit 1)\fR 
  719. .sp 9p
  720. .RT
  721. .PP
  722. The B and F bits are used for segmenting and reassembly of messages in 
  723. synchronous mode applications. Setting the B\ bit to\ \*Q1\*U indicates 
  724. that the frame contains an information portion beginning a message. Setting 
  725. the F\ bit 
  726. to\ \*Q1\*U indicates the frame contains the final portion of the message. 
  727. If the 
  728. entire message is contained within a single frame then both B and F\ bits 
  729. will be set to\ \*Q1\*U. A frame which is neither first nor last is termed 
  730. a middle 
  731. frame. For the asynchronous mode and the bit transparent mode these bits are
  732. set to\ \*Q1\*U.
  733. .bp
  734. .RT
  735. .ce
  736. \fBH.T. [T6.120]\fR 
  737. .ce
  738. TABLE\ 4/V.120
  739. .ce
  740. \fBCoding of B and F bits\fR 
  741. .ps 9
  742. .vs 11
  743. .nr VS 11
  744. .nr PS 9
  745. .TS
  746. center box;
  747. cw(12p) | cw(12p) | cw(60p) | cw(60p) | cw(60p) .
  748. B    F    Synchronous    Asynchronous    Bit transparent
  749. _
  750. .T&
  751. cw(12p) | cw(12p) | lw(60p) | lw(60p) | lw(60p) .
  752. 1    0    Begin frame    Not applicable    Not applicable
  753. _
  754. .T&
  755. cw(12p) | cw(12p) | lw(60p) | lw(60p) | lw(60p) .
  756. 0    0    Middle frame    Not applicable    Not applicable
  757. _
  758. .T&
  759. cw(12p) | cw(12p) | lw(60p) | lw(60p) | lw(60p) .
  760. 0    1    Final frame    Not applicable    Not applicable
  761. _
  762. .T&
  763. cw(12p) | cw(12p) | lw(60p) | lw(60p) | lw(60p) .
  764. 1    1    Single frame    Required    Required
  765. _
  766. .TE
  767. .nr PS 9
  768. .RT
  769. .ad r
  770. \fBTable 4/V.120 [T6.120], p.\fR 
  771. .sp 1P
  772. .RT
  773. .ad b
  774. .RT
  775. .LP
  776. .sp 1
  777. .sp 1P
  778. .LP
  779. 2.3.6
  780.     \fIControl state information\fR 
  781. .sp 9p
  782. .RT
  783. .PP
  784. The control state information is contained in the second octet of the header 
  785. when present. In general, for TAs, this field serves as a physical status/interface 
  786. control field for the interface at the R\ reference point. 
  787. Control state information may be sent whenever one of the mapped control 
  788. leads changes, although the TA should be able to accept the CS octet anytime 
  789. the 
  790. H\ field is present. Figure\ 5/V.120 shows the format of the control state
  791. information octet. For an example of the mapping of the V.24 leads, see
  792. Annex\ A. See \(sc\ 2.6 for the procedures and see \(sc\ 3.2.1 for the 
  793. use of the RR\ bit for flow control. 
  794. .RT
  795. .LP
  796. .rs
  797. .sp 12P
  798. .ad r
  799. \fBFigure 5/V.120 [T7.120], p.\fR 
  800. .sp 1P
  801. .RT
  802. .ad b
  803. .RT
  804. .sp 1P
  805. .LP
  806. .sp 1
  807. 2.3.6.1
  808.     \fIE\(hyextension bit (bit 8)\fR 
  809. .sp 9p
  810. .RT
  811. .PP
  812. The extension bit allows for further extension of the header
  813. octets. The E\ bit set to\ \*Q1\*U to indicate no further extension of the
  814. header.
  815. .RT
  816. .sp 1P
  817. .LP
  818. 2.3.6.2
  819.     \fIDR \(em data ready (bit 7)\fR 
  820. .sp 9p
  821. .RT
  822. .PP
  823. This bit set to \*Q1\*U indicates that the interface at the R reference 
  824. point is activated. For TE1 it implies the terminal interface is 
  825. activated.
  826. .bp
  827. .RT
  828. .sp 1P
  829. .LP
  830. 2.3.6.3
  831.     \fISR \(em send ready (bit 6)\fR 
  832. .sp 9p
  833. .RT
  834. .PP
  835. This bit set to \*Q1\*U indicates that the TE is ready to send
  836. data.
  837. .RT
  838. .sp 1P
  839. .LP
  840. 2.3.6.4
  841.     \fIRR \(em receive ready (bit 5)\fR 
  842. .sp 9p
  843. .RT
  844. .PP
  845. This bit set to \*Q1\*U indicates that the TE is ready to receive
  846. data.
  847. .RT
  848. .sp 1P
  849. .LP
  850. 2.3.6.5
  851.     \fIBits 4, 3, 2, 1\fR 
  852. .sp 9p
  853. .RT
  854. .PP
  855. Bits 4, 3, 2 and 1 of the control state information octet are
  856. reserved and set to\ \*Q0\*U.
  857. .RT
  858. .sp 1P
  859. .LP
  860. 2.3.7
  861.     \fIInterframe time fill\fR 
  862. .sp 9p
  863. .RT
  864. .PP
  865. Interframe time fill should normally be HDLC flags. For special
  866. applications it may be all ones.
  867. .RT
  868. .sp 1P
  869. .LP
  870. 2.4
  871.     \fIElements of procedure and procedures\fR 
  872. .sp 9p
  873. .RT
  874. .PP
  875. Two types of logical connections are available using the procedures described 
  876. in this specification, namely: 
  877. .RT
  878. .LP
  879.     1)
  880.     support of unacknowledged information transfer only (see
  881. \(sc\ 5.2 of Recommendation\ Q.921);
  882. .LP
  883.     2)
  884.     support of both multiple frame acknowledged information
  885. transfer and unacknowledged information transfer (see \(sc\ 5.5 of
  886. Recommendation\ Q.921).
  887. .PP
  888. For either type, the elements of procedure and procedures are as specified 
  889. in \(sc\(sc\ 3 and\ 5 of Recommendation\ Q.921, with the following 
  890. differences:
  891. .LP
  892.     \(em
  893.     C/R bit symmetry;
  894. .LP
  895.     \(em
  896.     receipt of I frame response;
  897. .LP
  898.     \(em
  899.     transmission of FRMR response;
  900. .LP
  901.     \(em
  902.     no TE1 management procedures;
  903. .LP
  904.     \(em
  905.     management of address field LLI.
  906. .PP
  907. These differences are detailed below.
  908. .sp 1P
  909. .LP
  910. 2.4.1
  911.     \fIC/R bit symmetry\fR 
  912. .sp 9p
  913. .RT
  914. .PP
  915. The use of the C/R bit is symmetric as described in \(sc 2.3.3.
  916. .RT
  917. .sp 1P
  918. .LP
  919. 2.4.2
  920.     \fIReceipt of I frame response\fR 
  921. .sp 9p
  922. .RT
  923. .PP
  924. During multiple frame acknowledged information transfer operation, I frames 
  925. sent as either commands or responses shall be received. I\ frame 
  926. responses are optional to send.
  927. .PP
  928. \fIQ.921 variable description\fR 
  929. .RT
  930. .LP
  931.     N(S)
  932.     Send sequence number
  933. .LP
  934.     N(R)
  935.     Receive sequence number
  936. .LP
  937.     V(R)
  938.     Next expected received N(S)
  939. .PP
  940. When a data link layer entity receives a valid I frame command
  941. whose N(S) is equal to the current V(R) and whose N(R) is in the proper 
  942. range, it shall follow the procedures stated in \(sc\(sc\ 5.6.2 and\ 5.6.6 
  943. of 
  944. Recommendation\ Q.921.
  945. .PP
  946. When a data link layer entity that is not in a timer recovery state
  947. receives a valid I\ frame response with F\ bit set to\ \*Q0\*U with its 
  948. N(S) equal to the current V(R) and whose N(R) is in the proper range, it 
  949. shall treat the 
  950. frame as a valid I\ frame command with P\ bit set to\ \*Q0\*U and follow the
  951. procedures stated in \(sc\(sc\ 5.6.2 and\ 5.6.6 of Recommendation\ Q.921. 
  952. If the 
  953. received I\ frame response has its F\ bit set to\ \*Q1\*U, the data link 
  954. layer entity shall indicate an error to the connection management entity. 
  955. .PP
  956. When a data link layer entity is in a timer recovery condition and
  957. receives a valid I\ frame response with F\ bit set to\ \*Q0\*U with its 
  958. N(S) equal to the current V(R) and whose N(R) is in the proper range, it 
  959. shall treat the 
  960. frame as a valid I\ frame command with P\ bit set to\ \*Q0\*U and follow the
  961. procedures stated in \(sc\(sc\ 5.6.2 and\ 5.6.6 of Recommendation\ Q.921.
  962. .bp
  963. .PP
  964. When a data link layer entity is in a timer recovery condition and
  965. receives a valid I\ frame response with F\ bit set to\ \*Q0\*U with its 
  966. N(R) in the 
  967. proper range, it shall clear the timer recovery condition and reset timer\ 
  968. T200 as if it had received a supervisory frame response with F\ bit set 
  969. to\ \*Q1\*U, as 
  970. described in \(sc\ 5.6.7 of Recommendation\ Q.921. If the I\ frame has 
  971. N(S) equal to the current V(R), it is then processed as if it were an I\ 
  972. frame command with 
  973. P\ bit set to\ \*Q0\*U, following the procedures stated in \(sc\(sc\ 5.6.2 
  974. and\ 5.6.6 of 
  975. Recommendation\ Q.921. If the I\ frame has N(S) not equal to the current V(R),
  976. the data link layer entity shall transmit a REJ command prior to resumption 
  977. of transmission or retransmission of I\ frames and enter the REJ exception 
  978. condition as described in \(sc\ 5.8.1 of Recommendation\ Q.921.
  979. .RT
  980. .sp 1P
  981. .LP
  982. 2.4.3
  983.     \fITransmission of FRMR response\fR 
  984. .sp 9p
  985. .RT
  986. .PP
  987. A frame rejection condition results from one of the
  988. following:
  989. .RT
  990. .LP
  991.     1)
  992.     the receipt of a supervisory or unnumbered frame with
  993. incorrect length;
  994. .LP
  995.     2)
  996.     the receipt of an invalid N(R);
  997. .LP
  998.     3)
  999.     the receipt of an I frame with an information field which
  1000. exceeds the maximum allowed length; or
  1001. .LP
  1002.     4)
  1003.      the receipt of a command or response control field that is undefined 
  1004. or not implemented. 
  1005. .PP
  1006. Upon occurrence of a frame rejection condition, the data link
  1007. layer entity shall:
  1008. .LP
  1009.     \(em
  1010.      transmit a FRMR response with F bit set to the value of the P bit in 
  1011. the rejected frame; 
  1012. .LP
  1013.     \(em
  1014.     indicate an error to the connection management entity; and
  1015. .LP
  1016.     \(em
  1017.      enter the \*Qmultiframe not established\*U state. The \*Qmultiframe not 
  1018. established\*U state is essentially equivalent to the \*QTE1 assigned\*U 
  1019. state 
  1020. described in Recommendation\ Q.921. It is the state initially entered by the
  1021. data link layer entity when the logical connection establishment procedure 
  1022. is completed successfully. 
  1023. .PP
  1024. The format and coding of the FRMR response is as shown in
  1025. Table\ 5/Q.921 and Figure\ 6/Q.921.
  1026. .sp 1P
  1027. .LP
  1028. 2.4.4
  1029.     \fINo TE1 management procedures\fR 
  1030. .sp 9p
  1031. .RT
  1032. .PP
  1033. The TE1 has no counterpart and the associated Recommendation\ Q.921 procedures 
  1034. for TE1 management do not apply. 
  1035. .RT
  1036. .sp 1P
  1037. .LP
  1038. 2.4.5
  1039.     \fIManagement of address field LLI\fR 
  1040. .sp 9p
  1041. .RT
  1042. .PP
  1043. The address field is managed using the procedures of \(sc\ 4.3.
  1044. .RT
  1045. .sp 1P
  1046. .LP
  1047. 2.5
  1048.     \fIData field length\fR 
  1049. .sp 9p
  1050. .RT
  1051. .PP
  1052. The maximum number of octets in a data field (N2xx) is a system
  1053. parameter. Its value must be less than or equal to N201 (see
  1054. Recommendation\ Q.921) minus the length of the header.
  1055. .RT
  1056. .sp 1P
  1057. .LP
  1058. 2.6
  1059.     \fIControl state information processing\fR 
  1060. .sp 9p
  1061. .RT
  1062. .PP
  1063. This section describes the use of the control state variables and the processing 
  1064. of the control state information field, when present, defined in \(sc\ 
  1065. 2.3.6. Use of the control state information field is optional (see octet\ 
  1066. 5b, bit\ 7 of low layer compatibility, \(sc\ 4.4.5). 
  1067. .PP
  1068. The terminal adaption entity maintains six control state variables
  1069. that indicate the current state of the DR, SR and RR indicators as
  1070. follows:
  1071. .RT
  1072. .LP
  1073.     \(em
  1074.      send variables DR(S), SR(S) and RR(S) \(em equal to the current local 
  1075. states of DR, SR and RR, respectively, as transmitted to the far end peer 
  1076. entity; 
  1077. .LP
  1078.     \(em
  1079.     receive variables DR(R), SR(R) and RR(R) \(em equal to the
  1080. current states of DR, SR and RR, respectively, in the peer entity as received 
  1081. from it. 
  1082. .sp 1P
  1083. .LP
  1084. 2.6.1
  1085.     \fIControl state information initialization\fR 
  1086. .sp 9p
  1087. .RT
  1088. .PP
  1089. Whenever the protocol is initialized to start communications, the protocol 
  1090. entity will set the receive variables (DR(R), SR(R) and RR(R)) to\ \*Q0\*U 
  1091. and the send state variables to reflect the status of the interface at 
  1092. the 
  1093. R\ reference point.
  1094. .bp
  1095. .RT
  1096. .sp 1P
  1097. .LP
  1098. 2.6.2
  1099.     \fISending a control state information field\fR 
  1100. .sp 9p
  1101. .RT
  1102. .PP
  1103. A control state information field will be sent whenever a send
  1104. control state variable changes. A send control state variable will change 
  1105. with a change to the interface at the R\ reference point or a change to 
  1106. a receive 
  1107. control state variable. The control state information held will be sent
  1108. following any queued data for interface at the S/T reference point. The 
  1109. control state information field is sent in the last frame containing data 
  1110. received 
  1111. across the interface at the R\ reference point prior to the control state
  1112. variable change, or in a separate frame.
  1113. .PP
  1114. The contents of the control state information octet is set to the
  1115. state of the corresponding send control state variables. DR is set to DR(S), 
  1116. SR is set to SR(S) and RR to RR(S). 
  1117. .RT
  1118. .sp 1P
  1119. .LP
  1120. 2.6.3
  1121.     \fIReceiving a control state information field\fR 
  1122. .sp 9p
  1123. .RT
  1124. .PP
  1125. Upon receipt of a control state information field, the control
  1126. field is checked with the receive control state variables: DR to DR(R), 
  1127. SR to SR(R) and RR to RR(R). The receive control state variables are set 
  1128. to their 
  1129. received values.
  1130. .PP
  1131. If SR(R) was \*Q0\*U and the SR bit in the received control state
  1132. information field is \*Q1\*U, then the interface at the R\ reference point 
  1133. and the RR(S) state are changed. 
  1134. .PP
  1135. If SR(R) was \*Q1\*U and the SR bit in the received control state
  1136. information field is \*Q0\*U, then the interface at the R\ reference point 
  1137. and the RR(S) state are changed, consistent with one of the following: 
  1138. .RT
  1139. .LP
  1140.     \(em
  1141.     if received data (from peer entity) does not remain to be
  1142. forwarded (no message in progress), then the control actions can occur
  1143. immediately;
  1144. .LP
  1145.     \(em
  1146.     if received data (from peer entity) is incomplete (e.g. in
  1147. protocol sensitive mode the final frame was not received), then the incomplete 
  1148. message is forwarded (continued) until completion on the interface at the 
  1149. R\ reference point, at which time the control actions can occur;
  1150. .LP
  1151.     \(em
  1152.     if received data (for peer entity) is complete, then the
  1153. received data is forwarded until completion on the interface at the R\ 
  1154. reference point, at which time the control actions can occur. 
  1155. .PP
  1156. If RR(R) and the RR bit in the received control state information field 
  1157. are not the same, then the interface at the R\ reference point is 
  1158. changed.
  1159. .PP
  1160. If DR(R) was \*Q0\*U and the DR bit in the received control state
  1161. information field is \*Q1\*U, then the interface at the R\ reference point is
  1162. changed.
  1163. .PP
  1164. If DR(R) was \*Q1\*U and the DR bit in the received control state
  1165. information field is \*Q0\*U, then the interface at the R\ reference point is
  1166. changed consistent with the following:
  1167. .RT
  1168. .LP
  1169.     \(em
  1170.     if the received message from the peer entity is incomplete,   it is discarded;
  1171. .LP
  1172.     \(em
  1173.      if the received message from the peer entity is a complete, message, 
  1174. then it should be forwarded to the interface at the R\ reference point 
  1175. until completetion prior to the control actions taking place. 
  1176. .sp 1P
  1177. .LP
  1178. 2.7
  1179.     \fIParameter negotiation\fR 
  1180. .sp 9p
  1181. .RT
  1182. .PP
  1183. Parameter negotiation during the bearer channel establishment is in accordance 
  1184. with the procedures described in CCITT Recommendation\ Q.931. During logical 
  1185. link negotiation, a specific value for a parameter may be requested by 
  1186. including the low layer compatibility information element containing the 
  1187. desired parameters in the SETUP message. The receiving TA may accept the
  1188. requested parameter values by responding with a CONNect message. If the
  1189. receiving TA does not accept the parameter values included in the SETUP
  1190. message, it may negotiate by including the desired values in a low layer
  1191. compatibility information element in the CONNect message. The originating TA
  1192. may refuse the parameters receiving in the connect message by initiating
  1193. clearing with the cause number\ 21 \*QCall Rejected\*U.
  1194. .RT
  1195. .sp 2P
  1196. .LP
  1197. \fB3\fR     \fBTerminal adaptor (TA) functions\fR 
  1198. .sp 1P
  1199. .RT
  1200. .sp 1P
  1201. .LP
  1202. 3.1
  1203.     \fIClock synchronization\fR 
  1204. .sp 9p
  1205. .RT
  1206. .PP
  1207. The specific mechanisms for providing clock synchronization is
  1208. implementation dependent. See Appendix\ II for a discussion.
  1209. .bp
  1210. .RT
  1211. .sp 1P
  1212. .LP
  1213. 3.2
  1214.     \fIData flow control and buffering\fR 
  1215. .sp 9p
  1216. .RT
  1217. .PP
  1218. Once a frame is assembled (from the interface at the R reference
  1219. point), it is sent on the interface at the S/T reference point at the nearest 
  1220. opportunity. V.120 procedures may control the flow of frames to the interface 
  1221. at the S/T reference point. The handling of overflow conditions will be 
  1222. described below in the appropriate sections on each mode of operation.
  1223. .RT
  1224. .sp 1P
  1225. .LP
  1226. 3.2.1
  1227.     \fIAsynchronous mode\fR 
  1228. .sp 9p
  1229. .RT
  1230. .PP
  1231. In the asynchronous mode, upon the TA receiving a frame from the
  1232. interface at the S/T reference point, the characters will be sent to the
  1233. interface at the R\ reference point at the earliest opportunity. In the
  1234. asynchronous mode under\(hyrun is not a problem, only the over\(hyrun condition 
  1235. is of concern. When all buffers are full, the TA flow controls the sender 
  1236. by not 
  1237. acknowledging until a buffer becomes available, when operating in multiple
  1238. frame acknowledged mode, or using the RR\ bit in the control state information 
  1239. octet, if available, when operating in unacknowledged mode. 
  1240. .PP
  1241. Flow control is indicated when a control state information field with the 
  1242. R\ bit set to\ \*Q0\*U is received. The flow control condition is removed 
  1243. when a flow controlled TA receives a control state information field with 
  1244. the RR\ bit set to\ \*Q1\*U. A TA may indicate a change in the state of 
  1245. the RR control state 
  1246. variable by sending UI\ frames with zero length V.110 information fields
  1247. containing the control state information field even when it is flow controlled 
  1248. by the other TA. 
  1249. .PP
  1250. \fINote\fR \ \(em\ Some asynchronous terminals may use local flow control.
  1251. .RT
  1252. .sp 1P
  1253. .LP
  1254. 3.2.2
  1255.     \fISynchronous mode\fR 
  1256. .sp 9p
  1257. .RT
  1258. .PP
  1259. In the synchronous mode, a possible under\(hyrun condition exists as well 
  1260. as the over\(hyrun. Adequate buffering should be provided to normally prevent 
  1261. under\(hyrunning the interface at the R\ reference point. 
  1262. .PP
  1263. If under\(hyrun towards the interface at the R reference point occurs,
  1264. the current message will be treated by sending an abort or forcing an FCS
  1265. error.
  1266. .PP
  1267. If an over\(hyrun occurs on buffers toward the interface at the S/T
  1268. reference point a frame will be sent across the interface at the S/T reference 
  1269. point indicating \*Qfinal\*U and having the C1 and C2 bits set to\ \*Q1\*U 
  1270. following any messages completely received from the interface at the R\ 
  1271. reference point. 
  1272. Additional data received from the interface at the R\ reference point will be
  1273. discarded until the start of a new message is detected.
  1274. .RT
  1275. .sp 1P
  1276. .LP
  1277. 3.2.3
  1278.     \fIBit transparent mode\fR 
  1279. .sp 9p
  1280. .RT
  1281. .PP
  1282. In the bit transparent mode, either under\(hyrun or over\(hyrun may
  1283. occur. In this mode the TE2s must operate at the same data rate. Adequate
  1284. buffering should be provided to minimize under\(hyrunning the interface at the
  1285. R\ reference point.
  1286. .PP
  1287. When the buffers are empty, the interface at the R reference point
  1288. will be set to the mark hold condition.
  1289. .PP
  1290. If the buffer to the interface at the S/T reference point over\(hyflows, 
  1291. the buffer pool will be set to empty state and accumulation of data 
  1292. restarted.
  1293. .RT
  1294. .sp 2P
  1295. .LP
  1296. 3.3
  1297.     \fIAsynchronous mode operation\fR 
  1298. .sp 1P
  1299. .RT
  1300. .sp 1P
  1301. .LP
  1302. 3.3.1
  1303.     \fICharacter processing \(em TE2 to S/T direction\fR 
  1304. .sp 9p
  1305. .RT
  1306. .PP
  1307. The following processing will be performed on start/stop data
  1308. received from the TE2:
  1309. .RT
  1310. .LP
  1311.     1)
  1312.     the start and stop bits will be removed from each
  1313. character;
  1314. .LP
  1315.     2)
  1316.     the remaining bit in the character may be checked for
  1317. correct parity;
  1318. .LP
  1319.     3)
  1320.      the parity bit will be removed if the code being used is an 8\(hybit 
  1321. code; otherwise passed as part of the octet; 
  1322. .LP
  1323.     4)
  1324.      codes using less than 8 bits (including parity) are padded in the high 
  1325. order bits. 
  1326. .PP
  1327. The resulting data is placed in frames, with the segment bits
  1328. indicating single segment and set to\ \*Q1\*U.
  1329. .PP
  1330. Frames may be sent based on a timer, after a certain frame size, after 
  1331. a carriage return,\ etc. However, the forwarding mechanism used is an 
  1332. implementation issue and may vary.
  1333. .bp
  1334. .PP
  1335. If a BREAK is detected by the TA on the interface at the R reference point, 
  1336. a frame with the BR\ bit set in the Header will be transmitted in the 
  1337. same frame or after all queued characters have been sent. The C1 and C2\ bits
  1338. should be set to\ \*Q0\*U.
  1339. .PP
  1340. If a parity error is detected on a character of data being received
  1341. from the TE2, the C1\ bit is set to\ \*Q1\*U and the frame sent following 
  1342. any frames already queued for transmission. Thus, setting of the C1\ bit 
  1343. to\ \*Q1\*U indicates that the last character in the frame in which the 
  1344. C1\ bit is set to\ \*Q1\*U was 
  1345. received by the TA with a parity error. If a stop bit error is detected on a
  1346. character of data being received from the TE2, the C2\ bit is set to\ \*Q1\*U 
  1347. and the frame sent following any frames already queued for transmission. 
  1348. Thus, setting of the C2\ bit to\ \*Q1\*U indicates that a stop bit error 
  1349. was detected by the TA 
  1350. immediately following the last character contained in the frame in which the
  1351. C2\ bit is set to\ \*Q1\*U.
  1352. .RT
  1353. .sp 1P
  1354. .LP
  1355. 3.3.2
  1356.     \fICharacter processing \(em S/T to TE2 direction\fR 
  1357. .sp 9p
  1358. .RT
  1359. .PP
  1360. The TA will perform the following processing on the data received from 
  1361. the interface at the S/T reference point: 
  1362. .RT
  1363. .LP
  1364.     1)
  1365.      if the asynchronous character is less than 8 data bits, the characters 
  1366. will be sent to the TE2 as is; 
  1367. .LP
  1368.     2)
  1369.     if the asynchronous character contains 8 data bits, each
  1370. character will be sent to the TE2 with the appropriate parity bit appended;
  1371. .LP
  1372.     3)
  1373.      if the C2 bit is set to \*Q1\*U indicating a stop bit error, the TA action 
  1374. is not defined; 
  1375. .LP
  1376.     4)
  1377.      if the C1 bit is set to \*Q1\*U and the asynchronous character contains 
  1378. 8\ data bits, indicating a parity error, then the TA may force a parity 
  1379. error on the last character sent to the TE2; 
  1380. .LP
  1381.     5)
  1382.      if the BREAK bit is set to \*Q1\*U, then the TA will send BREAK to the 
  1383. TE2 following all characters received prior to the break; 
  1384. .LP
  1385.     6)
  1386.     start and stop bits will be appended to the characters as
  1387. required.
  1388. .sp 2P
  1389. .LP
  1390. 3.4
  1391.     \fISynchronous mode operation\fR 
  1392. .sp 1P
  1393. .RT
  1394. .sp 1P
  1395. .LP
  1396. 3.4.1
  1397.     \fIMessage processing \(em TE2 to S/T direction\fR 
  1398. .sp 9p
  1399. .RT
  1400. .PP
  1401. The following processing will be performed on the HDLC frame
  1402. received from the TE2:
  1403. .RT
  1404. .LP
  1405.     1)
  1406.     the beginning flag(s) will be removed;
  1407. .LP
  1408.     2)
  1409.     all inserted zeros will be removed;
  1410. .LP
  1411.     3)
  1412.     FCS will be accumulated until a flag is detected. The
  1413. polynomial G(X)\ =\ X**16\ + X**12\ + X**\ 5\ +\ 1 will be used for the FCS
  1414. accumulation. The accumulated FCS will be compared with the FCS received 
  1415. from the TE2; 
  1416. .LP
  1417.     4)
  1418.      the FCS character received from the TE2 will be removed in all cases 
  1419. except for when UI\ frames are used to carry HDLC frames, in which 
  1420. case the FCS of the original HDLC frame is also carried as data;
  1421. .LP
  1422.     5)
  1423.     the ending flag will be removed.
  1424. .PP
  1425. The resulting data will be segmented, if necessary, with each
  1426. segment preceded by the header. Segmentation shall be such that no frame
  1427. transmitted on the interface at the S/T reference point is longer than N201
  1428. octets.
  1429. .PP
  1430. If only one segment is required, the header will indicate both
  1431. beginning segment and final segment in the \*QB\*U\ bit and the \*QF\*U\ 
  1432. bit. If more 
  1433. than one segment is required, the header of the first segment will indicate
  1434. \*Qbegin\*U segment and the last segment of the message will indicate \*Qfinal\*U 
  1435. segment. All intermediate segments will have both \*Qbegin\*U and \*Qfinal\*U 
  1436. segment indicators set to\ \*Q0\*U. 
  1437. .PP
  1438. The C1 and C2 bits will be set as follows in the final or only segment 
  1439. to indicate detected error conditions: 
  1440. .RT
  1441. .LP
  1442.     \(em
  1443.     if an FCS error is detected as a result of the FCS
  1444. accumulation process described in step\ 3 above, then the C2\ bit will be set
  1445. to\ \*Q1\*U with the C1\ bit set to\ \*Q0\*U;
  1446. .LP
  1447.     \(em
  1448.     if an abort sequence is detected on the interface at the
  1449. R\ reference point, then the C1\ bit will be set to\ \*Q1\*U with the C2\ 
  1450. bit set to 
  1451. \*Q0\*U;
  1452. .LP
  1453.     \(em
  1454.      if an over\(hyrun occurs on buffers toward the interface at the S/T reference 
  1455. point, as described above in \(sc\ 3.2.2, then both the C1 and 
  1456. C2\ bits will be set to\ \*Q1\*U.
  1457. .PP
  1458. When the TA first detects an HDLC idle condition on the interface at the 
  1459. R\ reference point, it will transmit a frame with the BR\ bit in the 
  1460. header set to\ \*Q1\*U following any queued data frames.
  1461. .bp
  1462. .sp 1P
  1463. .LP
  1464. 3.4.2
  1465.     \fIMessage processing \(em S/T to TE2 direction\fR 
  1466. .sp 9p
  1467. .RT
  1468. .PP
  1469. The TA will perform the following processing on the data
  1470. received:
  1471. .RT
  1472. .LP
  1473.     1)
  1474.     The header will be checked as follows:
  1475. .LP
  1476.     a)
  1477.     if the \*Qbegin\*U segment bit is \*Q1\*U and the previous
  1478. segment did not have the \*Qfinal\*U segment bit set to\ \*Q1\*U, then 
  1479. the previous 
  1480. message will be terminated with an ABORT sequence;
  1481. .LP
  1482.     b)
  1483.     if the \*Qbegin\*U segment bit is \*Q0\*U and there is no
  1484. message currently in process, the segment will be discarded;
  1485. .LP
  1486.     c)
  1487.      if the C1 and C2 error bit is \*Q1\*U with the \*Qfinal\*U bit a \*Q1\*U, 
  1488. an ABORT sequence will be sent to the TE2 instead of the FCS 
  1489. characters.
  1490. .LP
  1491.     2)
  1492.      The FCS is recalculated for TA reconstructed messages when transmitted 
  1493. at the interface at the R\ reference point except in the case where UI\ 
  1494. frames are used to carry HDLC frames. In this case the FCS of the original 
  1495. HDLC frame is used in the reconstructed frame. The TA has the option of 
  1496. examining the original FCS, which has been passed to it in the data stream 
  1497. and taking appropriate action. 
  1498. .PP
  1499. If an under\(hyrun occurs toward the interface at the R reference
  1500. point, then the frame being sent to the TE2 shall be treated as described in
  1501. \(sc\ 3.2.2.
  1502. .PP
  1503. If the BR bit is \*Q1\*U, then the TA will set an HDLC idle condition on 
  1504. the interface at the R\ reference point following data queued for transmission. 
  1505. The HDLC idle condition will be maintained until a frame is received with 
  1506. its BR\ bit set to\ \*Q0\*U. 
  1507. .RT
  1508. .sp 1P
  1509. .LP
  1510. 3.5
  1511.     \fIBit transparent mode operation\fR 
  1512. .sp 9p
  1513. .RT
  1514. .PP
  1515. The TA breaks synchronous data stream into fixed size frames and
  1516. sends it over the channel as it is received from the TE2. The TA takes data
  1517. from frames received and sends it to the TE2.
  1518. .PP
  1519. The terminal adaption header must be used in bit transparent mode if it 
  1520. is necessary to transmit the control state information. When the terminal 
  1521. adaption header is used in this mode C1 and C2\ bits must both be set to\ 
  1522. \*Q0\*U (no error). B and F\ bits must both be set to\ \*Q1\*U and reserve 
  1523. bits must be set 
  1524. to\ \*Q0\*U.
  1525. .PP
  1526. If an under\(hyrun occurs toward the interference at the R reference
  1527. point, then the frame being sent to the TE2 shall be treated as described in
  1528. \(sc\ 3.2.3.
  1529. .PP
  1530. For unique applications, the contents of a frame with an FCS error may 
  1531. be delivered across the interface at the R\ reference point. 
  1532. .RT
  1533. .sp 2P
  1534. .LP
  1535. \fB4\fR     \fBConnection control procedures\fR 
  1536. .sp 1P
  1537. .RT
  1538. .PP
  1539. This section describes the procedures for establishing connections for 
  1540. V.120 terminal adaption. Procedures are described for: 
  1541. .RT
  1542. .LP
  1543.     \(em
  1544.     establishment of an ISDN circuit\(hyswitched connection; and
  1545. .LP
  1546.     \(em
  1547.     optional procedures for the negotiation of logical link
  1548. identifiers.
  1549. .PP
  1550. The protocol described in the following sections describing
  1551. procedures for negotiating logical links is based on Recommendation\ Q.931
  1552. messages, information elements and procedures, but is tailored for this
  1553. particular application. It is differentiated from the full Recommendation\ 
  1554. Q.931 procedures by the use of a unique protocol identifier (\*Q00001001\*U). 
  1555. In addition to the information elements of Recommendation\ Q.931, an additional 
  1556. information element is required to convey the logical link identifier for 
  1557. this application and is defined in the following sections. 
  1558. .PP
  1559. The selection of V.120 as a terminal adaption protocol at the
  1560. establishment of the bearer channel is specified by information in the 
  1561. bearer capability information and/or low layer compatibility information 
  1562. elements of the bearer channel SETUP procedure. 
  1563. .PP
  1564. Logical link negotiation procedures may be carried out by means of
  1565. user information messages in a Recommendation\ Q.931 Call associated temporary 
  1566. signalling connection on the ISDN D\ Channel, or by means of logical link 
  1567. zero within the bearer channel using Recommendation\ Q.921 elements of 
  1568. procedure 
  1569. (i.e.\ either UI or I\ frames). The choice of methods is a terminal equipment
  1570. option and is partially determined by the availability of end\(hyto\(hyend ISDN
  1571. signalling capability. The optional establishment of logical links between
  1572. equipments that support different options may not be possible.
  1573. .bp
  1574. .RT
  1575. .sp 1P
  1576. .LP
  1577. 4.1
  1578.     \fIEstablishment of circuit\(hyswitched connection\fR 
  1579. .sp 9p
  1580. .RT
  1581. .PP
  1582. The bearer channel between the TAs is controlled using the
  1583. D\ channel signalling procedure for call establishment is described in
  1584. Recommendation\ Q.931.
  1585. .PP
  1586. On the basis of call setup information, the network provides a bearer channel 
  1587. to the requested end\(hypoint. The transfer mode and transfer capability 
  1588. in the bearer capability (BC) information element of the setup message 
  1589. is 
  1590. coded as circuit, unrestricted or restricted.
  1591. .RT
  1592. .sp 1P
  1593. .LP
  1594. 4.2
  1595.     \fIEstablishment of logical links\fR 
  1596. .sp 9p
  1597. .RT
  1598. .PP
  1599. This procedure requires that all TAs either be \*Qdefault assignees\*U 
  1600. or \*Qassignor only\*U. The TAs that must always assign the LLI (e.g.,\ 
  1601. TAs with 
  1602. pre\(hyassigned LLIs) are assignor only, all other TAs are default assignee. An
  1603. assignor/assignee field is provided in the low layer compatibility (LLC) 
  1604. and bearer capability (BC) information elements for V.120. This field must 
  1605. be coded as \*Q0\*U when the TA is a default assignee, and as \*Q1\*U when 
  1606. the TA is an assignor only. The \*Qdefault assignee\*U may assume the role 
  1607. of \*Qassignor only\*U during 
  1608. negotiation.
  1609. .RT
  1610. .sp 1P
  1611. .LP
  1612. 4.2.1
  1613.     \fIDuring the bearer channel setup phase\fR 
  1614. .sp 9p
  1615. .RT
  1616. .PP
  1617. The first logical link is established between the two TAs using the default 
  1618. LLI\ =\ 256 using the information provided in the LLC information 
  1619. element.
  1620. .RT
  1621. .sp 2P
  1622. .LP
  1623. 4.2.2
  1624.     \fIDuring the bearer channel active phase\fR 
  1625. .sp 1P
  1626. .RT
  1627. .sp 1P
  1628. .LP
  1629. 4.2.2.1
  1630.     \fIResolving when both sides are default assignees\fR 
  1631. .sp 9p
  1632. .RT
  1633. .PP
  1634. The first TA initiating a request for a logical link other than the default 
  1635. will assume the assignee role. The TA that receives that request will assume 
  1636. the assignor role. 
  1637. .PP
  1638. If both TAs simultaneously send SETUP messages, the SETUP message
  1639. containing the larger \*Qcall reference\*U (see Recommendation\ Q.931 for 
  1640. definition of call reference) is accepted and treated in accordance with 
  1641. the above 
  1642. procedure. The response to the SETUP message with the lower \*Qcall reference\*U 
  1643. is a RELease COMPlete message. If both SETUP messages contain the same 
  1644. \*Qcall 
  1645. reference\*U, they are both cleared with RELease COMPlete messages, and 
  1646. the TAs select different \*Qcall references\*U and try again. 
  1647. .RT
  1648. .sp 1P
  1649. .LP
  1650. 4.2.2.2
  1651.     \fILLI assignee\fR 
  1652. .sp 9p
  1653. .RT
  1654. .PP
  1655. If a TA is determined to be LLI assignee, it must set the
  1656. assignor/assignee field contained in any additional SETUP messages to zero.
  1657. .PP
  1658. The LLI assignee TAs request additional logical links by sending a
  1659. SETUP message without the LLI information element. The TA receiving this 
  1660. SETUP message assigns an LLI by including the LLI information element in 
  1661. the CONNect message. 
  1662. .RT
  1663. .sp 1P
  1664. .LP
  1665. 4.2.2.3
  1666.     \fILLI assignor\fR 
  1667. .sp 9p
  1668. .RT
  1669. .PP
  1670. If a TA is determined to be LLI assignor, it must set the
  1671. assignor/assignee field contained in any additional SETUP message to one.
  1672. .PP
  1673. The LLI assignor TAs set up additional logical links by sending SETUP messages 
  1674. that include the LLI information element. The receiving TA responds 
  1675. with a CONNect message and sets up a logical link using the information
  1676. provided in the SETUP message.
  1677. .RT
  1678. .sp 1P
  1679. .LP
  1680. 4.3
  1681.     \fIMessages used for logical connection control\fR 
  1682. .sp 9p
  1683. .RT
  1684. .PP
  1685. The following messages are used for establishing logical links
  1686. within a bearer channel.
  1687. .RT
  1688. .LP
  1689.     Call establishment
  1690.     SETUP
  1691. .LP
  1692. CONNect
  1693. .LP
  1694.     Call clearing
  1695.     RELease
  1696. .LP
  1697. RELease COMPlete
  1698. .bp
  1699. .sp 1P
  1700. .LP
  1701. 4.3.1
  1702.     \fISetup\fR 
  1703. .sp 9p
  1704. .RT
  1705. .PP
  1706. See Table 5/V.120.
  1707. .PP
  1708. This message is sent by either TA to indicate that it desires to
  1709. initiate a new logical link. It must contain protocol discriminator, call
  1710. reference, and message type. Low layer compatibility information element can
  1711. optionally be included in the SETUP message. Logical link identifier
  1712. information element must be included in the SETUP message if the TA is
  1713. assigning the LLI, and not included if requesting an LLI from the other
  1714. TA.
  1715. .RT
  1716. .ce
  1717. \fBH.T. [T8.120]\fR 
  1718. .ce
  1719. TABLE\ 5/V.120
  1720. .ce
  1721. \fBSETUP message content\fR 
  1722. .ps 9
  1723. .vs 11
  1724. .nr VS 11
  1725. .nr PS 9
  1726. .TS
  1727. center box;
  1728. cw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1729. Information element    Ref. V.120    Type    Length
  1730. _
  1731. .T&
  1732. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1733. Protocol discriminator    4.4.1    M    1
  1734. .T&
  1735. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1736. Call Reference    4.4.3    M    2
  1737. .T&
  1738. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1739. Message type    4.4.2    M    1
  1740. .T&
  1741. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1742. Low layer compatibility    4.4.5    O (Note 1)    2\(hy13
  1743. .T&
  1744. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1745. Logical link identifier    4.4.6    O (Note 2)    4
  1746. .TE
  1747. .LP
  1748. M\ Mandatory
  1749. O\ Optional
  1750. .LP
  1751. \fINote\ 1\fR
  1752. \ \(em\ Included when the calling user wants to pass low layer
  1753. compatibility information to the called user.
  1754. .LP
  1755. \fINote\ 2\fR
  1756. \ \(em\ Included if the calling user has the responsibility for assigning
  1757. LLI for that physical link.
  1758. .nr PS 9
  1759. .RT
  1760. .ad r
  1761. \fBTable 5/V.120 [T8.120], p.\fR 
  1762. .sp 1P
  1763. .RT
  1764. .ad b
  1765. .RT
  1766. .sp 1P
  1767. .LP
  1768. 4.3.2
  1769.     \fICONNect\fR 
  1770. .sp 9p
  1771. .RT
  1772. .PP
  1773. See Table 6/V.120.
  1774. .PP
  1775. This message is sent by the TA that has received a SETUP message to
  1776. indicate that the request for establishment of an additional logical link 
  1777. has been accepted. It must include protocol discriminator, call reference, 
  1778. and 
  1779. message type information elements. The low layer compatibility information
  1780. element can optionally be included in the CONNect message. The logical link
  1781. identifier information element must be included if not included in the SETUP
  1782. message, and is not included otherwise.
  1783. .RT
  1784. .ce
  1785. \fBH.T. [T9.120]\fR 
  1786. .ce
  1787. TABLE\ 6/V.120
  1788. .ce
  1789. \fBCONNect message content\fR 
  1790. .ps 9
  1791. .vs 11
  1792. .nr VS 11
  1793. .nr PS 9
  1794. .TS
  1795. center box;
  1796. cw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1797. Information element    Ref. V.120    Type    Length
  1798. _
  1799. .T&
  1800. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1801. Protocol discriminator    4.4.1    M    1
  1802. .T&
  1803. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1804. Call reference    4.4.3    M    2
  1805. .T&
  1806. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1807. Message type    4.4.2    M    1
  1808. .T&
  1809. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1810. Low layer compatibility    4.4.5    O (Note 1)    2\(hy13
  1811. .T&
  1812. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1813. Logical link identifier    4.4.6    O (Note 2)    4
  1814. .TE
  1815. .LP
  1816. \fINote\ 1\fR
  1817. \ \(em\ Included to allow the called user to negotiate low layer
  1818. compatibility information with the calling user.
  1819. .LP
  1820. \fINote\ 2\fR
  1821. \ \(em\ Included if the called user has the responsibility for assigning
  1822. LLI.
  1823. .nr PS 9
  1824. .RT
  1825. .ad r
  1826. \fBTable 6/V.120 [T9.120], p.\fR 
  1827. .sp 1P
  1828. .RT
  1829. .ad b
  1830. .RT
  1831. .LP
  1832. .bp
  1833. .sp 1P
  1834. .LP
  1835. 4.3.3
  1836.     \fIRELease\fR 
  1837. .sp 9p
  1838. .RT
  1839. .PP
  1840. See Table 7/V.120.
  1841. .PP
  1842. The RELease message is used to indicate that the TA intends to release 
  1843. the call reference and the logical link, and that the TA receiving this 
  1844. message must release the logical link and prepare to release the call reference 
  1845. after sending a RELease COMPlete. This message must contain protocol discriminator, 
  1846. call reference message type, and optionally cause information elements. 
  1847. .RT
  1848. .ce
  1849. \fBH.T. [T10.120]\fR 
  1850. .ce
  1851. TABLE\ 7/V.120
  1852. .ce
  1853. \fBRELease message content\fR 
  1854. .ps 9
  1855. .vs 11
  1856. .nr VS 11
  1857. .nr PS 9
  1858. .TS
  1859. center box;
  1860. cw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1861. Information element    Ref. V.120    Type    Length
  1862. _
  1863. .T&
  1864. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1865. Protocol discriminator    4.4.1    M    1
  1866. .T&
  1867. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1868. Call reference    4.4.3    M    2
  1869. .T&
  1870. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1871. Message type    4.4.2    M    1
  1872. .T&
  1873. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1874. Cause    4.4.4    O    2\(hy4  
  1875. _
  1876. .TE
  1877. .nr PS 9
  1878. .RT
  1879. .ad r
  1880. \fBTable 7/V.120 [T10.120], p.\fR 
  1881. .sp 1P
  1882. .RT
  1883. .ad b
  1884. .RT
  1885. .sp 1P
  1886. .LP
  1887. .sp 1
  1888. 4.3.4
  1889.     \fIRELease COMPlete\fR 
  1890. .sp 9p
  1891. .RT
  1892. .PP
  1893. See Table 8/V.120.
  1894. .PP
  1895. The RELease COMPlete message is sent to acknowledge that the TA
  1896. sending the message has released the logical link and call reference. This
  1897. message must contain protocol discriminator, call reference, and message 
  1898. type and optionally cause information elements. 
  1899. .RT
  1900. .ce
  1901. \fBH.T. [T11.120]\fR 
  1902. .ce
  1903. TABLE\ 8/V.120
  1904. .ce
  1905. \fBRELease COMPlete message content\fR 
  1906. .ps 9
  1907. .vs 11
  1908. .nr VS 11
  1909. .nr PS 9
  1910. .TS
  1911. center box;
  1912. cw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1913. Information element    Ref. V.120    Type    Length
  1914. _
  1915. .T&
  1916. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1917. Protocol discriminator    4.4.1    M    1
  1918. .T&
  1919. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1920. Call reference    4.4.3    M    2
  1921. .T&
  1922. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1923. Message type    4.4.2    M    1
  1924. .T&
  1925. lw(102p) | cw(42p) | cw(42p) | cw(42p) .
  1926. Cause    4.4.4    O    2\(hy4  
  1927. _
  1928. .TE
  1929. .nr PS 9
  1930. .RT
  1931. .ad r
  1932. \fBTable 8/V.120 [T11.120], p.\fR 
  1933. .sp 1P
  1934. .RT
  1935. .ad b
  1936. .RT
  1937. .sp 2P
  1938. .LP
  1939. .sp 1
  1940. 4.4
  1941.     \fIInformation elements\fR 
  1942. .sp 1P
  1943. .RT
  1944. .sp 1P
  1945. .LP
  1946. 4.4.1
  1947.     \fIProtocol discriminator\fR 
  1948. .sp 9p
  1949. .RT
  1950. .PP
  1951. The protocol discriminator is \*Q00001001\*U.
  1952. .RT
  1953. .sp 1P
  1954. .LP
  1955. 4.4.2
  1956.     \fIMessage type\fR 
  1957. .sp 9p
  1958. .RT
  1959. .PP
  1960. Message types are identical to message types in
  1961. Recommendation\ Q.931.
  1962. .bp
  1963. .RT
  1964. .sp 1P
  1965. .LP
  1966. 4.4.3
  1967.     \fICall reference\fR 
  1968. .sp 9p
  1969. .RT
  1970. .PP
  1971. The call reference field should be two octets in length.
  1972. .RT
  1973. .sp 1P
  1974. .LP
  1975. 4.4.4
  1976.     \fICause information element\fR 
  1977. .sp 9p
  1978. .RT
  1979. .PP
  1980. See Figure 6/V.120.
  1981. .RT
  1982. .LP
  1983. .sp 1
  1984. .rs
  1985. .sp 19P
  1986. .ad r
  1987. \fBFigure 6/V.120 [T12.120] \ \ 
  1988. (\*`a traiter comme tableau), p.\fR 
  1989. .sp 1P
  1990. .RT
  1991. .ad b
  1992. .RT
  1993. .sp 1P
  1994. .LP
  1995. .sp 5
  1996. 4.4.5
  1997.     \fILow layer compatibility information element\fR 
  1998. .sp 9p
  1999. .RT
  2000. .PP
  2001. See Figure 7/V.120.
  2002. .RT
  2003. .sp 1P
  2004. .LP
  2005. 4.4.6
  2006.     \fILogical link identifier information element\fR 
  2007. .sp 9p
  2008. .RT
  2009. .PP
  2010. The purpose of the logical link identifier information element is to identify 
  2011. a logical link within the bearer channel. The default length of 
  2012. this element is four octets. The logical link identifier information element 
  2013. is coded as shown in Figure 8/V.120. 
  2014. .RT
  2015. .sp 1P
  2016. .LP
  2017. 4.5
  2018.     \fILogical connection control procedures\fR 
  2019. .sp 9p
  2020. .RT
  2021. .PP
  2022. This optional procedure defines the method for negotiation logical
  2023. links other than the default (LLI\ =\ 256). For setup and clearing of the 
  2024. bearer channel, the procedure described in Recommendation\ Q.931 must be 
  2025. followed. 
  2026. .bp
  2027. .RT
  2028. .LP
  2029. .rs
  2030. .sp 47P
  2031. .ad r
  2032. \fBFigure 7/V.120 [1T13.120] \ \ 
  2033. (\*`a traiter comme tableau), p.15\fR 
  2034. .sp 1P
  2035. .RT
  2036. .ad b
  2037. .RT
  2038. .LP
  2039. .bp
  2040. .LP
  2041. .rs
  2042. .sp 43P
  2043. .ad r
  2044. \fBFigure 7/V.120 [2T13.120] \ \ 
  2045. (\*`a traiter comme tableau), p.16\fR 
  2046. .sp 1P
  2047. .RT
  2048. .ad b
  2049. .RT
  2050. .LP
  2051. .bp
  2052. .LP
  2053. .rs
  2054. .sp 4P
  2055. .ad r
  2056. Blanc
  2057. .ad b
  2058. .RT
  2059. .LP
  2060. .bp
  2061. .LP
  2062. .rs
  2063. .sp 17P
  2064. .ad r
  2065. \fBFigure 8/V.120 [T14.120] \ \ 
  2066. (\*`a traiter comme tableau), p.17\fR 
  2067. .sp 1P
  2068. .RT
  2069. .ad b
  2070. .RT
  2071. .LP
  2072. .sp 1
  2073. .sp 1P
  2074. .LP
  2075. 4.5.1
  2076.     \fILogical link establishment\fR 
  2077. .sp 9p
  2078. .RT
  2079. .PP
  2080. A logical link may be established by either TA by sending a SETUP   message.
  2081. .PP
  2082. If the TA sending the SETUP message assigns the LLI, the SETUP message 
  2083. must also include the assigned LLI value for the logical link. 
  2084. .PP
  2085. If the TA does not assign the LLI, it must not include the LLI
  2086. information element in the SETUP message. In this case the LLI is assigned 
  2087. by the receiving TA by including an LLI information element in the CONNect 
  2088. message.
  2089. .PP
  2090. A TA may request a logical link by sending a SETUP message, setting
  2091. timer\ T303, and entering \*Qcall initiated\*U state.
  2092. .PP
  2093. If no response to the SETUP message is received before the first
  2094. expiry of timer\ T303, the SETUP message must be transmitted and timer\ T303
  2095. restarted. After the second expiry of timer\ T303, the \*QNull\*U state 
  2096. is entered. 
  2097. .PP
  2098. A TA receiving the SETUP message must send a CONNect message and enter 
  2099. the \*QActive\*U state if able; otherwise, it must send a RELease COMPlete 
  2100. message and enter the \*QNull' state. 
  2101. .PP
  2102. When the initiating TA receives the CONNect message, it must stop
  2103. timer\ T303, and enter the \*QActive\*U state.
  2104. .RT
  2105. .sp 1P
  2106. .LP
  2107. 4.5.2
  2108.     \fILogical link clearing\fR 
  2109. .sp 9p
  2110. .RT
  2111. .PP
  2112. Either TA may request to clear a logical link by sending a RELease message, 
  2113. setting timer\ T308, and entering \*QRelease Request\*U state. 
  2114. .PP
  2115. When a TA receives a RELease message, it must release the logical
  2116. link, send a RELease COMPlete message, release the call reference, and enter
  2117. the \*QNull\*U state.
  2118. .PP
  2119. When the TA initiating a RELease receives RELease COMPlete message, it 
  2120. must stop timer\ T308, release the logical link, release the call reference, 
  2121. and enter the \*QNull\*U state. 
  2122. .PP
  2123. If the TA initiating the RELease does not receive a RELease COMPlete message 
  2124. before the first expiry of timer\ T308, the RELease message must be 
  2125. retransmitted and timer\ T308 restarted. If RELease COMPlete message is not
  2126. received before timer\ T308 expires for the second time, the TA must release 
  2127. the call reference and enter the logical link into the \*QNull\*U state. 
  2128. .PP
  2129. If both TAs simultaneously request to clear the same logical link by sending 
  2130. RELease messages, both must stop timer\ T308, release the logical link, 
  2131. release the call reference, and enter the \*QNull\*U state. 
  2132. .bp
  2133. .RT
  2134. .ce 1000
  2135. ANNEX\ A
  2136. .ce 0
  2137. .sp 1P
  2138. .ce 1000
  2139. (to Recommendation V.120)
  2140. .sp 9p
  2141. .RT
  2142. .ce 0
  2143. .sp 1P
  2144. .ce 1000
  2145. \fBMappings of V.24 circuits to DR, SR, and RR\fR 
  2146. .sp 1P
  2147. .RT
  2148. .ce 0
  2149. .PP
  2150. This Annex describes mapping of V.24 circuits intended to
  2151. provide proper operation with most DTEs.
  2152. .sp 1P
  2153. .RT
  2154. .sp 1P
  2155. .LP
  2156. A.1
  2157.     \fIDR\(hydata ready (bit 7)\fR 
  2158. .sp 9p
  2159. .RT
  2160. .PP
  2161. The DR bit maps according to DTE attachment as follows:
  2162. .RT
  2163. .LP
  2164.     \(em
  2165.     for sending DR\(hyDR(S) state variable:
  2166. .LP
  2167.     \(em
  2168.      indicates DTR\(hydata terminal ready (Recommendation V.24 circuit 108/2) 
  2169. from DTE; 
  2170. .LP
  2171.     \(em
  2172.     for receiving DR\(hyDR(R) state variable: no mapping is
  2173. required.
  2174. .PP
  2175. \fINote\fR \ \(em\ Dropping DTR may be used by the TE2 to indicate to the 
  2176. TA to clear the logical link or call. 
  2177. .sp 1P
  2178. .LP
  2179. A.2
  2180.     \fISR\(hysend ready (bit 6)\fR 
  2181. .sp 9p
  2182. .RT
  2183. .PP
  2184. The SR bit maps according to DTE attachment as follows:
  2185. .RT
  2186. .LP
  2187.     \(em
  2188.     for sending SR\(hySR(S) state variable;
  2189. .LP
  2190.     \(em
  2191.     indicates request to send (RTS \(em Recommendation V.24
  2192. circuit 105) status from DTE;
  2193. .LP
  2194.     \(em
  2195.     for receiving SR\(hySR(R) state variable;
  2196. .LP
  2197.     \(em
  2198.     drives receive line signal detect (RLSD \(em
  2199. Recommendation\ V.24 circuit\ 109) to DTE;
  2200. .LP
  2201.     \(em
  2202.      the received ST bit is also mapped to the send RR bit (i.e.\ SR(R)\ \(ra\ 
  2203. RR(S)). 
  2204. .sp 1P
  2205. .LP
  2206. A.3
  2207.     \fIRR\(hyreceive ready (bit 5)\fR 
  2208. .sp 9p
  2209. .RT
  2210. .PP
  2211. The RR bit maps according to DTE attachment as follows:
  2212. .RT
  2213. .LP
  2214.     \(em
  2215.     for sending RR\(hyRR(S) state variable: no mapping is required;
  2216. .LP
  2217.     \(em
  2218.     for receiving RR\(hyRR(R) state variable:
  2219. .LP
  2220.     \(em
  2221.     drives ready for send (RFS \(em Recommendation V.24
  2222. circuit 106) to DTE.
  2223. \v'6p'
  2224. .ce 1000
  2225. APPENDIX\ I
  2226. .ce 0
  2227. .sp 1P
  2228. .ce 1000
  2229. (to Recommendation V.120)
  2230. .sp 9p
  2231. .RT
  2232. .ce 0
  2233. .sp 1P
  2234. .ce 1000
  2235. \fBTE1 application\fR 
  2236. .sp 1P
  2237. .RT
  2238. .ce 0
  2239. .PP
  2240. The protocols and procefures defined in Recommendation V.120 may be used 
  2241. for data transport by compatible TE1s as well as terminal adapters (TAs). 
  2242. In the TE1 case, the interface at the R\ reference point is effectively 
  2243. replaced by a virtual interface within the TE1 to a higher layer entity. 
  2244. This appendix describes the application of Recommendation\ V.120 in TE1s. 
  2245. .sp 1P
  2246. .RT
  2247. .sp 2P
  2248. .LP
  2249. I.1
  2250.     \fIAsynchronous mode operation\fR 
  2251. .sp 1P
  2252. .RT
  2253. .sp 1P
  2254. .LP
  2255. I.1.1
  2256.     \fITransmission onto the ISDN channel\fR 
  2257. .sp 9p
  2258. .RT
  2259. .PP
  2260. The B, F bits are set to \*Q1\*U, and the C1 and C2 bits in the header 
  2261. are set to\ \*Q0\*U. The data to be transmitted is segmented as required, 
  2262. and each segment is appended to the header before transmission. 
  2263. .PP
  2264. If a BREAK is received from the next higher layer, a frame with the BR 
  2265. bit set to\ \*Q1\*U in the header will be transmitted at the earliest opportunity 
  2266. following data queued for transmission.
  2267. .bp
  2268. .RT
  2269. .sp 1P
  2270. .LP
  2271. I.1.2
  2272.     \fIReception from the ISDN channel\fR 
  2273. .sp 9p
  2274. .RT
  2275. .PP
  2276. Processing of received data is as follows, based on the values of the C1 
  2277. and C2\ bits in the header: 
  2278. .RT
  2279. .LP
  2280.     \(em
  2281.     if the C1 and C2 bits are both set to \*Q0\*U, the received
  2282. characters are forwarded to the next higher layer without error indication;
  2283. .LP
  2284.     \(em
  2285.      if the C1 bit is set to \*Q1\*U, then a parity error indication is forwarded 
  2286. to the next higher layer with the characters received; the parity error 
  2287. applies to the last character in the frame; 
  2288. .LP
  2289.     \(em
  2290.     if the C2 bit is set to \*Q1\*U, then a stop\(hybit error is
  2291. forwarded to the next higher layer with the characters received; the error
  2292. occurred immediately following the last character in the frame.
  2293. .PP
  2294. If the BR bit is set to \*Q1\*U in the header of the received frame, then 
  2295. a BREAK indication is forwarded to the next higher layer after all data 
  2296. queued has been forwarded.
  2297. .sp 1P
  2298. .LP
  2299. I.2
  2300.     \fISynchronous mode operation\fR 
  2301. .sp 9p
  2302. .RT
  2303. .PP
  2304. The messages passed to and received from the higher layer include the HDLC 
  2305. address and control fields, but do not include HDLC flags, FCS or 
  2306. inserted \*Q0\*Us.
  2307. .RT
  2308. .sp 1P
  2309. .LP
  2310. I.2.1
  2311.     \fITransmission onto the ISDN channel\fR 
  2312. .sp 9p
  2313. .RT
  2314. .PP
  2315. The message length is compared with N2xx. The message is processed depending 
  2316. on its length as follows: 
  2317. .RT
  2318. .LP
  2319.     \(em
  2320.      if the message length is less than or equal to N2xx, then the entire 
  2321. message is appended behind the header and both in the B and F\ bits set 
  2322. to\ \*Q1\*U. The resulting message is then transmitted; 
  2323. .LP
  2324.     \(em
  2325.     if the message length is greater than N2xx, the first N2xx
  2326. octets are appended to the header, with the B\ bit set to\ \*Q1\*U and 
  2327. the F\ bit set to\ \*Q0\*U. The resulting message is then transmitted; 
  2328. .LP
  2329.     \(em
  2330.      if the remaining portion of the message is greater in length than N2xx, 
  2331. the next N2xx octets are appended to the header, with both 
  2332. the B and F\ bits set to\ \*Q0\*U. The resulting message is then transmitted;
  2333. .LP
  2334.     \(em
  2335.      if the length of the remaining portion of the message is less than or 
  2336. equal to N2xx, then the remaining portion of the message is 
  2337. appended to the header with the F\ bit set to\ \*Q1\*U and the B\ bit set 
  2338. to\ \*Q0\*U. The resulting message is then transmitted. 
  2339. .PP
  2340. The C1 and C2 bits are normally set to \*Q0\*U.
  2341. .sp 1P
  2342. .LP
  2343. I.2.2
  2344.     \fIReception from the ISDN channel\fR 
  2345. .sp 9p
  2346. .RT
  2347. .PP
  2348. Any messages that were segmented at the transmit end are
  2349. reassembled as indicated by the B and F header bits.
  2350. .PP
  2351. The header of a received frame will be checked for error conditions as follows:
  2352. .RT
  2353. .LP
  2354.     \(em
  2355.     if the \*Qbegin\*U segment bit is \*Q1\*U and the previous segment
  2356. did not have the \*Qfinal\*U segment bit set to\ \*Q1\*U, then the previous 
  2357. message will be aborted; 
  2358. .LP
  2359.     \(em
  2360.     if the \*Qbegin\*U segment bit is set to \*Q0\*U and there is no
  2361. message currently in process, the segment will be discarded;
  2362. .LP
  2363.     \(em
  2364.      if the C1 or C2 error bit is \*Q1\*U with the \*Qfinal\*U bit a \*Q1\*U, 
  2365. the message will be discarded. 
  2366. .PP
  2367. If a frame is received with the BR bit set to \*Q1\*U in the header, then 
  2368. the TE1 management entity will be notified of an HDLC idle condition sent 
  2369. from the far end. The HDLC idle condition is maintained until a frame is 
  2370. received with the BR\ bit in its header set to\ \*Q0\*U.
  2371. .PP
  2372. When a message has been reassembled it is passed to the next higher
  2373. layer.
  2374. .RT
  2375. .sp 2P
  2376. .LP
  2377. I.3
  2378.     \fIBit transparent mode operation\fR 
  2379. .sp 1P
  2380. .RT
  2381. .sp 1P
  2382. .LP
  2383. I.3.1
  2384.     \fITransmission onto the ISDN channel\fR 
  2385. .sp 9p
  2386. .RT
  2387. .PP
  2388. The transmitting entity accepts data from the process using its
  2389. services, segments the data into segments of length at most N2xx, and transmits 
  2390. that data within frame to its peer entity. The length of the data segments 
  2391. and the length of the transmitted interframe time fill are adjusted so 
  2392. that the 
  2393. average data transmission rate matches the rate selected during call
  2394. establishment.
  2395. .bp
  2396. .RT
  2397. .sp 1P
  2398. .LP
  2399. I.3.2
  2400.     \fIReception from the ISDN channel\fR 
  2401. .sp 9p
  2402. .RT
  2403. .PP
  2404. The receiving entity upon receiving a frame from its peer entity, checks 
  2405. the FCS and if the FCS is valid it passes any data contained in the 
  2406. frame to the process using its services. If the FCS is not valid the entity
  2407. may, on an application specific basis, discard the data contained in the
  2408. errored frame or pass that data, with or without error indication, to the
  2409. process using the services of the entity.
  2410. .RT
  2411. .sp 1P
  2412. .LP
  2413. I.4
  2414.     \fITE1 control state variable processing\fR 
  2415. .sp 9p
  2416. .RT
  2417. .PP
  2418. In TE1 applications, the six control state variable DR(S), SR(S), RR(S), 
  2419. DR(R), SR(R), and RR(R) are maintained as described in \(sc\ 2.3.6, with 
  2420. the following meanings: 
  2421. .RT
  2422. .LP
  2423.     \(em
  2424.     for sending DR \(em DS(S) state variable:
  2425. .LP
  2426.     \(em
  2427.     indicates that the sending TE1 is powered up and
  2428. connected for communication;
  2429. .LP
  2430.     \(em
  2431.     for receiving DR \(em DR(R) state variable:
  2432. .LP
  2433.     \(em
  2434.      indicates that the sending TE1 (far end) is powered up and connected 
  2435. for communication; 
  2436. .LP
  2437.     \(em
  2438.     for sending SR \(em SR(S) state variable:
  2439. .LP
  2440.     \(em
  2441.     indicates that the sending TE1 is ready to send
  2442. frames;
  2443. .LP
  2444.     \(em
  2445.     for receiving SR \(em SR(R) state variable:
  2446. .LP
  2447.     \(em
  2448.     indicates that the sending TE1 (far end) is ready to
  2449. send frames;
  2450. .LP
  2451.     \(em
  2452.     for sending RR \(em RR(S) state variable:
  2453. .LP
  2454.     \(em
  2455.     indicates that the sending TE1 is ready to receive
  2456. frames;
  2457. .LP
  2458.     \(em
  2459.     for receiving RR \(em RR(R) state variable:
  2460. .LP
  2461.     \(em
  2462.     indicates that the sending TE1 (far end) is ready to
  2463. receive frames.
  2464. .PP
  2465. The following sections describe the procedures for control state variable 
  2466. processing in a TE1 using V.120. Note that the control states in a TE1 
  2467. as described above are essentially analogous to those in a TA as described 
  2468. in \(sc\ 2.3.6. Thus, the TE1 control state variable processing described 
  2469. below is 
  2470. completely compatible with that described in \(sc\ 2.6 for the TA.
  2471. .sp 1P
  2472. .LP
  2473. I.4.1
  2474.     \fIControl state variable initialization\fR 
  2475. .sp 9p
  2476. .RT
  2477. .PP
  2478. Whenever the protocol is initialized to start communications, the protocol 
  2479. entity will set the receive state variables (DR(R), SR(R), and RR(R)) to\ 
  2480. \*Q0\*U and the send state variables to reflect the status of the TE1 as 
  2481. described above.
  2482. .RT
  2483. .sp 1P
  2484. .LP
  2485. I.4.2
  2486.     \fISending a control state information octet\fR 
  2487. .sp 9p
  2488. .RT
  2489. .PP
  2490. A control state information octet will be sent whenever a send
  2491. control state variable changes. A send control state variable will change 
  2492. with a change to the state of the TE1 as described above. A frame containing 
  2493. the 
  2494. control state information octet will be sent following any queued data 
  2495. for the interface at the S/T reference point. 
  2496. .PP
  2497. The control state information field is sent in the last frame
  2498. assembled when the control state change occurs, or in a separate frame.
  2499. .PP
  2500. The contents of the control state information octet is set to the
  2501. state of the corresponding send control state variables. DR is set to DR(S), 
  2502. SR is set to SR(S), and RR to RR(S). 
  2503. .RT
  2504. .sp 1P
  2505. .LP
  2506. I.4.3
  2507.     \fIReceiving a control state information octet\fR 
  2508. .sp 9p
  2509. .RT
  2510. .PP
  2511. Upon receipt of a control state information octet, the control
  2512. field is checked with the receive control state variables: DR to DR(R), 
  2513. SR to SR(R), and RR to RR(R). The receive control state variables are set 
  2514. to their 
  2515. received values.
  2516. .PP
  2517. If SR(R) was \*Q0\*U and the SR bit in the received control state
  2518. information octet is \*Q1\*U, notification is made to the TE1 management 
  2519. entity. 
  2520. .PP
  2521. If SR(R) was \*Q1\*U and the SR bit in the received control state
  2522. information octet is \*Q0\*U, notification is made to the TE1 management entity
  2523. consistent with one of the following:
  2524. .RT
  2525. .LP
  2526.     \(em
  2527.      if received data (from the peer entity) does not remain to be forwarded 
  2528. (no message in progress), then the control actions can occur 
  2529. immediately;
  2530. .LP
  2531.     \(em
  2532.      if received data (from the peer entity) is incomplete (e.g. in protocol 
  2533. sensitive mode the final frame is not received), then the 
  2534. incomplete message is forwarded with indication of incomplete message and 
  2535. the notification made to the TE1 management entity; 
  2536. .LP
  2537.     \(em
  2538.     if received data (from the peer entity) is complete, the
  2539. message is forwarded and the notification of the TE1 management entity
  2540. occurs.
  2541. .bp
  2542. .PP
  2543. If RR(R) and the RR bit in the received control field differ,
  2544. notification is made to the TE1 management entity.
  2545. .PP
  2546. If DR(R) was \*Q0\*U and the RR bit in the received control field is \*Q1\*U, 
  2547. notification is made to the TE1 management entity. 
  2548. .PP
  2549. If DR(R) was \*Q1\*U and the DR bit in the received control field is \*Q0\*U, 
  2550. then notification is made to the TE1 management entity consistent with 
  2551. the 
  2552. following:
  2553. .RT
  2554. .LP
  2555.     \(em
  2556.     if received data from peer entity is incomplete, it is
  2557. discarded;
  2558. .LP
  2559.     \(em
  2560.      if received data from peer entity is a complete message, then it should 
  2561. be forwarded until completion prior to the control actions taking 
  2562. place.
  2563. \v'1P'
  2564. .ce 1000
  2565. APPENDIX\ II
  2566. .ce 0
  2567. .sp 1P
  2568. .ce 1000
  2569. (to Recommendation V.120)
  2570. .sp 9p
  2571. .RT
  2572. .ce 0
  2573. .sp 1P
  2574. .ce 1000
  2575. \fBClock synchronization\fR 
  2576. .sp 1P
  2577. .RT
  2578. .ce 0
  2579. .PP
  2580. Figure II\(hy1/V.120 shows two DTE/DCE configurations and their respective 
  2581. clock synchronization. 
  2582. .sp 1P
  2583. .RT
  2584. .LP
  2585. .rs
  2586. .sp 25P
  2587. .ad r
  2588. \fBFigure II\(hy1/V.120, p.\fR 
  2589. .sp 1P
  2590. .RT
  2591. .ad b
  2592. .RT
  2593. .PP
  2594. In the first case in Figure II\(hy1/V.120, the TA is providing the
  2595. clocks to the DTE or DCE. In the second case in Figure\ II\(hy1/V.120, the DCE
  2596. provides the Receive Clock to the TA for data to the DTE, and the TA at 
  2597. the DTE end provides the Receive Clock to the DTE for this same data. 
  2598. .PP
  2599. There are three strategies which could be used for clock tracking. The 
  2600. first is to use the data buffers as clock variance buffers by having these 
  2601. buffers absorb the accumulated clock variance. In this case, no clock tracking 
  2602. is performed. If the buffer is completely depleted, and under\(hyrun occurs 
  2603. causing an error on the synchronous interface at the R\ reference point. 
  2604. Buffer space over\(hyrun can also happen, causing an error. However, the 
  2605. buffer 
  2606. accumulation or depletion to the point of over\(hyrun or under\(hyrun due 
  2607. to clock 
  2608. error is a slow process and is predictable in the worst case within the 
  2609. CCITT clock tolerance of 100\ parts per 
  2610. .bp
  2611. .PP
  2612. million. The second strategy is for   the clocks
  2613. at both ends to be synchronized to the network. This strategy solves the
  2614. problem but is not applicable to case\ 2 in Figure\ II\(hy1/V.120. The third
  2615. strategy is to monitor the buffer state as data is being received from the
  2616. interface at the S/T reference point in the TA that is providing the Receive
  2617. Clock to the DTE. This strategy monitors the rate of data at this interface 
  2618. by checking the buffer state when a new frame is received, and adjusts 
  2619. the clock speed accordingly. 
  2620. .PP
  2621. For asynchronous applications, the first strategy (no clock
  2622. correction) should be sufficient. For these applications a clock tolerance 
  2623. of +1/\(em2.5% is permissible, see Recommendation\ V.14. Under\(hyrun is 
  2624. not possible and buffering in the TA should be sufficient to avoid over\(hyrun. 
  2625. .PP
  2626. For synchronous mode applications, appropriate buffer setup and
  2627. management using no clock correction should be sufficient.
  2628. .PP
  2629. For bit transparent mode applications, continuous data does not allow for 
  2630. buffer resynchronization. For case\ 2 the frames are read into a buffer 
  2631. at the receiving TA and are clocked out to the TE2 by a time source derived 
  2632. in the TA. If the data is clocked out at the rate transmitted, each frame 
  2633. will fill 
  2634. the receive buffer to precisely the same level. If the rate is low the fill
  2635. level will increase and provide an indication that the clock rate must be
  2636. increased and vice versa.
  2637. .PP
  2638. In some implementations, the clock adjustments might be in the form of 
  2639. repeated small adjustments in the phase of the clock, which would be derived 
  2640. from the ISDN network clock. Where the TE2 is tolerant of large phase steps 
  2641. the process may be simple. 
  2642. .RT
  2643. .ce 1000
  2644. APPENDIX\ III
  2645. .ce 0
  2646. .sp 1P
  2647. .ce 1000
  2648. (to Recommendation V.120)
  2649. .sp 9p
  2650. .RT
  2651. .ce 0
  2652. .sp 1P
  2653. .ce 1000
  2654. \fBBearer channel initialization procedures\fR 
  2655. .sp 1P
  2656. .RT
  2657. .ce 0
  2658. .ce 1000
  2659. \fBfor circuit switched applications\fR 
  2660. .ce 0
  2661. .PP
  2662. To reduce the possibility of transmitting a frame to a TA that is not yet 
  2663. connected: 
  2664. .sp 1P
  2665. .RT
  2666. .LP
  2667.     \(em
  2668.      a TA that receives a CONNect message from the network should always transmit 
  2669. a frame to initiate the connection, and 
  2670. .LP
  2671.     \(em
  2672.     a TA that receives a CONNect ACKnowledge message from the
  2673. network should wait for T200 or until it receives a frame (whichever is
  2674. earlier) before transmitting a frame.
  2675. .LP
  2676. .rs
  2677. .sp 23P
  2678. .sp 2P
  2679. .LP
  2680. \fBMONTAGE: RECOMMANDATION V.230 SUR LE RESTE DE CETTE PAGE\fR 
  2681. .sp 1P
  2682. .RT
  2683. .LP
  2684. .bp
  2685.